Alyssa Ross [Fri, 14 Feb 2025 11:26:11 +0000 (12:26 +0100)]
libostree: add private dependencies to pkg-config
This makes it possible to use pkg-config to link against libostree as
a static library. Unlike shared libraries, static libraries don't
encode their dependencies in the library file, so we have to
communicate them via pkg-config.
fossdd [Mon, 27 Jan 2025 16:49:39 +0000 (17:49 +0100)]
libotutil: Remove redundant import of prctl.h
sys/prctl.h already provides prctl.h and adding both imports fails on
musl libc:
/usr/include/sys/prctl.h:88:8: error: redefinition of 'struct prctl_mm_map'
88 | struct prctl_mm_map {
| ^~~~~~~~~~~~
In file included from src/libotutil/ot-unix-utils.c:33:
/usr/include/linux/prctl.h:134:8: note: originally defined here
134 | struct prctl_mm_map {
| ^~~~~~~~~~~~
Basically our composefs enablement flag has long had a tension between
trying to do two things:
- Enable generating the composefs blob (at deployment time)
- Enable at runtime in prepare-root
And we've hit issues in "ratcheting" enabling composefs
across upgrades because of this.
This change builds on the previous one, and now it's really
simple to talk about:
- If composefs is enabled at build time, we *always*
generate a composefs blob at deplyment time
- Configuring the prepare-root config now mostly
only affects the runtime state.
There is one detail though: in order to handle the
verity requirement at deploy time, we do still parse
the config then.
But for the basic "is composefs enabled at all at runtime"
that is now fully keyed off the config, not the build time
or (worse) whether the deployment happened to have a composefs
blob.
For users who want composefs on, they need to do so in the base
image configuration.
Mary Strodl [Thu, 12 Dec 2024 14:30:59 +0000 (09:30 -0500)]
bin/admin-upgrade: add kexec support
Adds a new `--kexec` flag to `ostree admin upgrade` which will cause
the deployment to be loaded into kexec after the upgrade completes.
It is particularly useful in conjunction with the `--reboot` flag to
perform a reboot into the new deployment without waiting for the
(often slow) firmware initialization to take place. (And in my case,
allows me to avoid a normal reboot, which can be unreliable on my
hardware).
After an image has been loaded (using the `kexec_file_load` syscall),
the `systemctl-reboot` command (which is called when the existing
`-r` flag is included) will trigger a kexec on the loaded image
rather than a normal reboot. From `systemctl(1)`:
If a new kernel has been loaded via kexec --load, a kexec will be
performed instead of a reboot, unless "SYSTEMCTL_SKIP_AUTO_KEXEC=1"
has been set. If a new root file system has been set up on
"/run/nextroot/", a soft-reboot will be performed instead of a
reboot, unless "SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1" has been set.
A good in-depth technical explanation of kexec can be found here:
https://web.archive.org/web/20090505132901/http://www.ibm.com/developerworks/linux/library/l-kexec.html
My implementation uses the `kexec_file_load` syscall rather than the
older `kexec_load` syscall, which allows the kernel to verify the
signatures of the new kernel. It is supported on Linux 3.17 and
newer. I assume this probably won't be an issue, but if it is, it's
not that hard to put a preprocessor directive around the kexec stuff
to disable it for older kernels. Even RHEL is new enough now to
not be an issue :)
Colin Walters [Fri, 6 Dec 2024 19:57:19 +0000 (14:57 -0500)]
man: Note semantics combining `root.transient` with `composefs.enabled`
It's all quite confusing having to reason about both the pre-composefs
ostree and the composefs version. But hopefully soon we more firmly
leave behind that first legacy.
Jonathan Lebon [Sat, 14 Dec 2024 13:47:21 +0000 (08:47 -0500)]
lib/deploy: error out if composefs enabled but unsupported
If composefs was explicitly requested (`enabled = true`) but libostree
was not compiled with composefs support, error out at deploy time. This
matches the logic in `ostree-prepare-root`.
Jonathan Lebon [Sat, 14 Dec 2024 13:45:19 +0000 (08:45 -0500)]
libostree/deploy: enable composefs by default
The composefs libostree integration has been supported for a while now
and is actively in use in various ostree/bootc-based systems. Let's
turn it on by default.
This has no effect if composefs support is not compiled in. Note also
that this does not change the default value of the `composefs.enabled`
tristate to `true`. The default is still `maybe`, but the deploy API
will now also create composefs images for `maybe`.
The reason for doing it this way is so that systems upgrading from
old libostree versions (which may either not have composefs support or
may have composefs-related bugs) will still be able to upgrade and not
trip `ostree-prepare-root` in the new deployment (which allows missing
composefs images for `maybe`).
We may in the future change the default value to `true`.
See also: https://github.com/ostreedev/ostree/issues/2867
Colin Walters [Wed, 27 Nov 2024 02:15:23 +0000 (21:15 -0500)]
core: Always sort incoming xattrs
When recomputing selinux attrs during commit, we weren't sorting,
which could cause various issues like fsck failures.
This is a big hammer; change things so we always canonicalize
(i.e. sort) the incoming xattrs when creating a file header
and directory metadata.
I think almost all places in the code were already keeping
things sorted, but it's better to ensure correctness first.
If we ever have some performance issue (I'm doubtful) we
could add something like `_ostree_file_header_known_canonicalized`
or so.
Closes: https://github.com/ostreedev/ostree/issues/3343 Signed-off-by: Colin Walters <walters@verbum.org>
Colin Walters [Mon, 4 Nov 2024 18:48:56 +0000 (13:48 -0500)]
prepare-root: Fix composefs docs
In practice in ostree-sysroot-deploy.c we only react to having
`composefs = yes`; the docs mention `maybe` but that never did
anything.
The value is wrong in the code too, but I'm not touching
that here to avoid conflating changes - the main thing to fix
is the docs because here `maybe == no`.
Colin Walters [Wed, 30 Oct 2024 14:07:26 +0000 (10:07 -0400)]
checkout: Only verify digest if repo requires fsverity
Fixes a regression from the previous commit; in
the case where the target repo doesn't have composefs in
signed mode there's no reason to verify the digest
at checkout time because we aren't verifying it at
boot time either.
The regression is in cases that use rpm-ostree e.g.
where as of recently we unconditionally add the composefs
digest, but for e.g. FCOS we aren't deploying with fsverity
enabled.
Closes: https://github.com/ostreedev/ostree/issues/3330 Signed-off-by: Colin Walters <walters@verbum.org>
Simon McVittie [Thu, 31 Oct 2024 10:54:13 +0000 (10:54 +0000)]
tests: Work around GPG 2.2.45 error behaviour when revoking an expired key
In GPG 2.2.45, a diagnostic message about the only trusted key having
already expired causes this import to produce exit status 2, but the
import still succeeds (the key is still revoked).
Colin Walters [Sun, 27 Oct 2024 14:20:29 +0000 (10:20 -0400)]
deploy: Don't recompute verity checksums if not enabled
This fixes a truly horrific performance bug when
composefs is enabled, but fsverity is not supported
by the filesystem. We'd fall back to doing *userspace*
checksumming of all files at deployment time which was absolutely
not expected or required.
There's really an immense amount of technical debt
here, such as the confusion between `ex-integity.composefs`
vs the prepare-root config, how we handle "torn" states
where some objects don't have verity enabled but some do,
etc.
The ostree composefs state has two modes:
- signed: We need to enforce fsverity
- unsigned: Best effort resilience
So we fix this by making the deploy path to make verity
"opportunistic" - if the ioctl gives us the data, then we
add it to the composefs.
However, this code path is also invoked when we're
computing the expected composefs digest to inject
as commit metadata, and *that* API must work regardless
of whether the target repo has fsverity enabled as
it may operate on a build server.
One lucky thing in all of this: When I went to add
the "checkout composefs" API I added a stub `GVariant`
for options extensibility, which we now use.
Colin Walters [Wed, 18 Sep 2024 17:41:59 +0000 (13:41 -0400)]
curl: Make socket callback during cleanup into no-op
Because curl_multi_cleanup may invoke callbacks, we effectively have
some circular references going on here. See discussion in
https://github.com/curl/curl/issues/14860
Basically what we do is the socket callback libcurl may invoke into a no-op when
we detect we're finalizing. The data structures are owned by this object and
not by the callbacks, and will be destroyed below. Note that
e.g. g_hash_table_unref() may itself invoke callbacks, which is where
some data is cleaned up.
Dan Nicholson [Sun, 15 Sep 2024 19:59:36 +0000 (13:59 -0600)]
workflow/docs: Fix deployments
A couple fixes to make PRs and non-PRs work correctly:
* In a conditional expression, `true` or `false` are returned unless you
terminate both sides in a ternary. That was causing 2 strings to be
suffixed with `false` instead of an empty string.
* For a PR, we do actually want to cancel in progress runs since there's
no danger of breaking an in progress deployment.
* For PRs, just use the same `github-pages-pr` name for the artifact.
The important part is that it's not called `github-pages` where an in
progress deployment could pick it up. Otherwise it can use the same
name all the time.
projects / ostree.git / log